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The Sensor Test for Orion Relative-Navigation Risk Mitigation (STORRM) Develop- 
ment Test Objective (DTO) flew aboard the Space Shuttle Endeavour on STS-134, and was 
designed to characterize the performance of the flash LIDAR being developed for the Orion. 

This flash LIDAR, called the Vision Navigation Sensor (VNS), will be the primary navi- 
gation instrument used by the Orion vehicle during rendezvous, proximity operations, and 
docking. This paper provides an overview of the STORRM test objectives and the concept 
of operations. It continues with a description of the STORRM’s major hardware compo- 
nents, which include the VNS and the docking camera. Next, an overview of crew and 
analyst training activities will describe how the STORRM team prepared for flight. Then 
an overview of how in-flight data collection and analysis actually went is presented. Key 
findings and results from this project are summarized, including a description of ’’truth” 
data. Finally, the paper concludes with lessons learned from the STORRM DTO. 

I. Introduction 

The Orion Crew Exploration Vehicle (CEV) is a new crewed vehicle being designed by NASA and Lock- 
heed Martin to ferry humans to/from the International Space Station (ISS) and other possible exploration 
destinations. One particularly challenging flight phase of the Orion mission is rendezvous, proximity opera- 
tions, and docking (RPOD). The unique requirements and constraints of the Orion vehicle make off-the-shelf 
relative navigation sensors insufficient for achieving the required relative navigation performance. Therefore, 
a new relative navigation sensor is being developed. The Vision Navigation Sensor (VNS) is a flash LIDAR 
and will be the primary navigation instrument used by the Orion during the RPOD flight phase. 

Past experience suggests that on-orbit testing is critical to gaining confidence that the VNS will perform as 
expected. In fact, as is shown in Fig. 1, many previous relative navigation sensors have experienced difficulties 
on-orbit that were not predicted by ground testing. This need led the Orion GNC team to propose the Sensor 
Test for Orion Relative-Navigation Risk Mitigation (STORRM) Development Test Objective (DTO). 

The STORRM DTO is scheduled to fly aboard the Space Shuttle Endeavour on STS 134, and will test 
the Orion Vision Navigation Sensor (VNS) and the high-resolution Docking Camera (DC) in an on-orbit 
environment. The objective is to collect data from these sensors to mitigate the loss-of-mission risk in 
upcoming Orion test flights and to increase the technology readiness level (TRL) of these sensors. 
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Figure 1. Historical survey of difficulties experienced by previous relative navigation sensors. 


II. Mission Objectives &; Concept of Operations 

The overall STORRM Mission Objectives are to test the on-orbit performance of the VNS and the 
DC on three different trajectories: (l)a nominal Orbiter RPOD trajectory to the ISS, (2) a nominal Orbiter 
undocking trajectory from the ISS, and (3) an Orion flight rendezvous/proximity operations trajectory to the 
ISS. To meet these objectives the Space Shuttle will separate from the ISS and then perform an unprecedented 
re-rendezvous with the ISS to within 1000 feet. The mission objectives are achieved by meeting the flight 
test objectives identified for each of the sensors. A summary of those flight test objectives are shown in 
Table 1 for the VNS, and in Table 2 for the DC. 

To achieve these flight test objectives, plans were put into place with the Shuttle Program to allow 
for command and control of the sensors and recording rates from a laptop computer in the crew cabin. 
Various parameters that will eventually be controlled internally to the sensors were externally controlled 
for STORRM. To facilitate the commands to the sensors, a STORRM Software Application (SSA) was 
developed. This laptop application will be monitored by a Mission Specialist during the mission. One of 


Table 1. Summary of VNS objectives. 


Objective 

Primary 

Secondary 

Characterize the ISS in the VNS wavelength (hot spots, reflectance map, etc.) 

X 


Determine initial acquisition range 

X 


Prove operation with large relative velocities 

X 


Collect data through known break track and reacquire conditions 

X 


Prove tracking through accelerations while maneuvering 

X 


Demonstrate transition between 3-DoF and pose modes 

X 


Allow for overlap with ground testing facilities 

X 


Collect data to support pose calculation 

X 


Characterize the ISS PMA2 augmented docking target 

X 


Determine range of pose acquisition 


X 

Prove tracking through TPI-type maneuver 


X 

Long range “loss of signal” 


X 
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Table 2. Summary of DC objectives. 


Objective Primary Secondary 

Prove operation in harsh orbital lighting conditions X 

Collect images to support assessment of validity for piloting cues X 

Assess DC as a potential backup to star tracker for mid-range bearings X 

Collect images to support Natural Feature Image Recognition analysis X 


the goals for the SSA was to minimize crew time and interaction, which lead to the implementation of a 
range-based control of the sensor settings. The range was obtained from either Orbiter onboard filtered 
range or from the Orbiter laser sensor, the Trajectory Control Sensor (TCS). The TCS data will later be 
used as “truth” measurements for comparison with the VNS data. 

Primary STORRM data collection opportunities will take place on flight day 3 (day of rendezvous with 
ISS) and flight day 13 (day of undock) of the STS 134 mission. Preceding each data collection, a special 
procedure and software phase will be executed. This procedure is called “Tools Checkout.” Tools Checkout 
consists of a timed set of operations which mode the sensors and data recorders in a predetermined sequence. 
Completion of Tools Checkout assures the proper function of the STORRM equipment and all associated 
connections from onboard through the ground are properly made. 

Data collection for the experiment is divided in to phases: Rendezvous, Undock, Re-Rendezvous and 
Separation. The phases, which are bounded by significant environmental or operational events, represent 
the highest level of decomposition of the mission time-line. The Orbiter trajectory, look-angle to ISS, 
ISS reflector assets, orbital lighting, sensor configuration, and various other parameters are unique to each 
phase. These differences provide a variety of collection opportunities from which to better evaluate the 
sensors. Astronaut action is required to place the SSA into the proper phase of data collection. Within each 
phase of data collection, the sensor settings are controlled through range bins. Upon entering a new range 
bin, a set of commands are sent to the sensors and data recorders to properly configure the system for data 
collection over that range. Sensor settings such as VNS gain, detector settings, field-of-view (FOV) size, and 
DC data recording are examples of range-based commands. Within each range bin, timed commanding also 
takes place. The timed commands control the region of interest upon which the DC is calculating automatic 
gain and exposure settings. This allows the STORRM team to collect valuable performance data on different 
region of interest sizes that will feed into Orion decisions for DC operations. 

III. Overview of STORRM Hardware 

The major components on the STORRM experiment are the Sensor Enclosure Assembly, Avionics Enclo- 
sure Assembly, Payload General Support Computer, Crew and Ground Operations Station. Each component 
and their major subsystems are described in the following paragraphs. 

The Sensor Enclosure Assembly (SEA) is located on the Orbited Docking System (ODS) Truss adjacent to 
the relative navigation sensor used by the Orbiter, the Trajectory Control Sensor (TCS). The SEA enclosure 
contains a the VNS, DC, and keep-alive heaters. The SEA is co-located with the TCS for better truth 
comparison and to avoid line-of-sight limitations. 

The Avionics Enclosure Assembly (AEA) is located on the port sidewall of Payload Bay 3. The AEA 
consists of data recorders that receive data from the sensors in the SEA, data storage units that store the 
collected data, and a Power Distribution Unit (PDU) that distributes power to the SEA and AEA. The AEA 
also passes sensor configuration commands to/from the PGSC and SEA. 

The Payload General Support Computer (PGSC) is located in the flight deck of the Orbiter crew cabin. 
The PGSC is loaded with an application that will initiate data collection and allow the crew and the ground 
to monitor the health and status of the systems. The experiment is controlled via crew inputs to the PGSC 
application. 

The Ground Operations Station (GOS) consists of computer terminals located in the Mission Control 
Center (MCC) in Houston, Texas, which also have access to real-time Orbiter telemetry and voice loops. 
The STORRM personnel monitor the sensor experiment data on the ground at the MCC. 

An Orbiter crew member will configure the PGSC and initiate a PGSC application to allow data to 
be collected automatically. A crew member will also configure the system as necessary when phases of the 
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experiment have concluded. 

Finally, power and data cables are routed from the SEA on the ODS Truss to the AEA on the payload 
bay sidewall and then through the Orbiter bulkhead into the STORRM PGSC in the crew cabin. Data 
from the experiment will be downlinked via Sequential Still Video (SSV) and the Orbiter Communications 
Adapter (OCA). An accurate time signature is provided from the Orbiter. This time signal, called the 
Payload Timing Buffer (PTB), is routed into the AEA from the Shuttle Payload Bay. 

IV. Crew and Analyst Training Activities 

The STORRM system interfaces with numerous Orbiter systems and levies unique trajectory require- 
ments on the Orbiter. Because STORRM is highly embedded in the STS 134 mission plan the training 
activities for the experiment required a three pronged approach: 

1. One-on-one sessions with the mission specialist 

2. Stand-alone Simulations with all crew members 

3. Joint Integrated Simulations with all the STS 134 ground personnel 

The one-on-one sessions with the Mission Specialist assigned to STORRM were the primary opportunity 
to explain the experiment background, LIDAR operation, and the hardware architecture. Additionally, 
sensitivities relating to the Mission Objectives, and operational timeline were conveyed in these sessions. 

The second approach used was Stand-alone Simulations. Stand-alone Simulations are crew training 
activities that involve all the Shuttle Crew and their timeline of activities as it would happen on the Orbiter 
during the mission. Stand-alone Simulations take place in the fixed base Shuttle Mission Simulator (SMS) 
at the NASA Johnson Space Center. The curriculum of these training opportunities focused on execution of 
the STORRM procedures and proper interface with the STORRM PGSC. Intentional failures are inserted 
into these training sessions. This training environment provides insight into the intersystem dependencies 
and helps identify crew workload issues. 

The third training approach, the Joint Integrated Simulations, are large scale training opportunities for 
the entire ensemble of Flight Controllers and analysts involved in the mission. STORRM ground personnel 
used these opportunities to become accustomed to the voice loop protocols, the SSV telemetry path and 
various Mission Control resources provided for situational awareness. Joint Integrated Simulations provided 
end-to-end training for the STS 134 flight. 

To carry out this suite of training activities a set of hardware and software components was developed to 
provide a functional equivalent of the AEA and SEA. This configuration of hardware and software is called 
the the STORRM Avionics Module. It mimics the physical and electrical interfaces between the PGSC and 
the AEA. 

In addition to the suite of training activities described above, STORRM was given the opportunity to 
demonstrate the operation of the flight hardware and software to the crew members of STS 134. This training 
experience was extremely valuable to the crew in that it provided insight into the system timing and sensor 
image quality that was unachievable in other ground simulations. 

This paper will discuss in greater detail the challenges encountered establishing and conducting the 
extensive training required to meet the STORRM objectives. 

V. Data Downlink 

Experimental data is transferred to analysts on the ground in two ways: in near real-time through a TV 
system called Sequential Still Video (SSV) and through a retrieval-downlink process which is called Data 
Retrieval Mode. The SSV data path employs the Orbiter Photo TV system and the PGSCs ability to render 
a virtual screen. This data path is configured such that high priority telemetry items are drawn to the virtual 
screen and then the virtual screen is interleaved into the Orbiter Photo TV stream to the Mission Control 
Center (MCC). Although the SSV data path is relatively fast (on the order of minutes), the information 
received is reduced significantly from the volume of data collected. The second way data is transferred to 
the ground, via Data Retrieval Mode, allows for all data, sensor image, and system health to be analyzed. 
In Data Retrieval Mode, the PGSC first copies unprocessed blocks of memory from the data storage drives 
in the Payload Bay on to the PGSC local disk drive. The blocks of data are copied to the from the PGSC 
disk drive to data storage in MCC via the Orbiter on-board network. The advantages, disadvantages, and 
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methods employed to maximize the information received will be discussed in greater detail in the full paper. 


VI. Data Analysis 

A number of tools were developed to quickly process the STORRM data collected on flight day 3 to 
determine if any modifications are necessary prior to the undocking and re-rendezvous that will occur on 
flight day 13. Upon receiving the data on the ground, data integrity checks are performed and the data is 
parsed into a “snapshot” format. This snapshot format means that each individual VNS or DC data file 
contains data collected at a single time, along with the appropriate header file. This snapshot data is then 
fed into either the VNS Quick Look Tool or the DC Quick Look Tool. 

The VNS Quick Look Tool is capable of interpreting raw STORRM VNS snapshot data and plotting 
raw range and intensity images. It is also capable of performing image processing on raw STORRM data 
to provide bearings and ranges to centroids of candidate reflectors at a user specified rate. Data may be 
processed for only a single measurement, or a large volume of data may be processed in a batch format. 
The ability to process only a single measurement (which is actually created by processing a number of 
STORRM VNS images) is useful in helping the analyst understand the performance of the sensor. A user- 
defined region of interest may be defined in the VNS Quick Look Tool and the analyst can zoom in on a 
particular portion of the image. The tool provides summary statistics of the raw intensity, raw range, and 
processed image in this region of interest. For either the single-measurement or batch-processing modes, it 
is possible to save raw data, JPEG pictures, and movies. The output of the VNS Quick Look Tool may be 
used to qualitatively assess the performance of the STORRM VNS. A more quantitative assessment may 
be performed by comparing the VNS centroid results with the TCS measurements. Further, the outputs 
may be fed into a reflector identification algorithm, coupled with a relative navigation filter, to obtain an 
assessment of the resulting relative navigation performance. 

The DC Quick Look Tool is capable of interpreting raw STORRM DC snapshot data and plotting raw 
and processed images. The raw DC data is still mosaiced (the detector uses a Bayer pattern), so the DC 
Quick Look Tool contains a demosaicing algorithm to reconstruct the color image (the user still has the 
option to either view a grayscale image or a color image). A number of image processing algorithms are 
available to the user to adjust the color gains, contrast, and brightness. The DC Quick Look Tool is capable 
of processing and saving a user defined set of data (e.g. a singe image, an arbitrary set of selected images, all 
the images in a target folder, etc.). Additionally, the user can specify region of interest and the DC Quick 
Look Tool will provide a zoomed-in plot of this region. This is particularly useful in assessing the quality of 
the DC for piloting cues. The STORRM DC images will also be compared with images from the Orbiter’s 
docking camera. 

The final version of this paper will include example VNS and DC images from the STORRM flight data. 

VII. Lessons Learned 

The final paper will include a thorough discussion of STORRM lessons learned. What follows are a few 
examples of some of the lessons that the team has learned: 

1. Requirements should be written with emphasis on system capability, not for a specific concept of 
operations. 

2. All procedures should be bookended (begin and end) at some stable state. They should be compart- 
mentalized into indivisible sequences of events. 

3. The philosophy of fault detection and troubleshooting measures should be chosen in the design phase. 

4. Parallel test ports should be implemented on all flight hardware elements. 
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